PASKAL: Object Program Structure 


by BILL FINDLAY 


0. Readership 


This document is a complement to PASKAL: Users’ Guide [Findlay6] and PASKAL: Implementation Overview [Findlay 1]. 
It collects in one place information about the structure of the Usercode object program generated by the KDF9 Pascal 
cross-compiler, PASKAL and is intended for anyone wishing to understand, maintain or enhance it. PASKAL comprises a 
Pascal program, paskal, and an Ada ‘peephole optimizer’, glance. It is supported by ee9 [Findlay3], my KDF9 
emulator, by David Holdsworth’s ka13 Usercode assembler, and by bash-compatible shell scripts. When I refer to 
PASKAL in the following I mean the paskal/glance combination. When I mean only the compiler, I say paskal. For 
more information about glance, see PASKAL: Implementation Overview. 


If you just want to use PASKAL, see PASKAL: Users’ Guide. 


1. Runtime organization and the stack 


Running programs make use of three stacks: the Pascal activation record stack of the object program, the NEST, and the 
SJNS. The NEST is a 16-deep pushdown store where KDF9’s postfix operations find their operands and deliver their result. 
The SJNS (‘Subroutine Jump Nesting Store’) is a 16-deep pushdown store of subroutine return addresses. For more 
information about the KDF9’s architecture, see [Findlay4] and [ICL1]. There is also a ‘heap’ where pointer-based data 
structures may be allocated. 

Expressions are evaluated in the NEST. At the end of a statement the NEST and the SJNS are usually empty. To be more 
precise, the SJNS may contain a single return address during the execution of a leaf procedure or function, and after an 
assignment the NEST may contain a copy of the assigned value if that is immediately used as an operand by the following 
statement. No other precaution is taken to avoid overfilling the NEST or SJNS. 

The activation record stack implemented by PASKAL grows up toward higher addresses, from YO, which is just past the 
end of the object code, within the Usercode ‘Y store’ area [Findlay5]. The heap grows down from the highest allocated 
address, identified in Usercode as ‘Z0’. Its address is written ‘AZO’ and the address of Y store y is written ‘AYy’. 

The Frame Pointer, Stack Pointer, Environment Pointer and Heap Pointer are addresses of words in the range of Y stores, 
all but the last being held in the M parts of Q stores. The Frame Pointer is held in the M part of Q1, namely M1, the Stack 
Pointer is in M2, and the Environment Pointer (the lexically-enclosing scope’s Frame Pointer) is in M3. 

Q4 is used to address non-local data other than that in the immediately-enclosing scope, and is also used (with Q15) as a 
‘scratch’ register for various other purposes. 


The Heap Pointer is in ZO and AYO = M1 = M2 < Z0 (N.B. ZO, not AZO). 


Q1, Q2 and Q3 are set up on entry to a subprogram by its ‘prelude’ and restored by its “postlude’ on return to a caller. The 
prelude and postlude take account of the properties of a subprogram. For example, they omit setting up M3 for a routine 
that does no non-local access. 


As well as its prelude and postlude, a scope may also have an ‘interlude’. This is created when the scope declares a Pascal 
label that is the target of a goto statement within an enclosed scope. It restores the execution environment of the target 
label, by restoring Q1, Q2 and Q3, as necessary, and then jumping to the label. 


Global variables are addressed directly as Yy. Local variables and parameters are addressed relative to the Frame Pointer as 
EeM1. Variables and parameters of the immediately-enclosing scope are addressed relative to the Environment Pointer as 
EeM3. Variables and parameters of outer enclosing scopes are similarly addressed relative to M4, which is set to point to 
that scope’s most recently active stack frame. 


The Pascal stack frame, or activation record, at its greatest elaboration, is laid out as follows: 
e EOM1 holds the Static Link, a copy of the Environment Pointer 
e EIMI holds the Dynamic Link, a copy of the Frame Pointer 
e E2M1 holds the return address 
e E3M1 holds the function result, which is unused in the case of a procedure 
e E4M1 holds the block serial number when symbolic dumping is implemented; if so v = 5 else v = 4, in the following 
e EvM1 .. Ew+v-1M1 is local variable storage, w = (number of words of local data) 
e E-pM1 .. E-1M1 is actual parameter storage, p = (number of parameter words) 


The Static Link and the Dynamic Link are copies made on entry to a routine, say P. They are used to restore Q1, Q2 and Q3 
on return from a further call, within P, that changes these registers. They are also used to restore Q1, Q2 and Q3 when a 
goto in an inner scope targetting a non-local Pascal label re-enters the scope of the label. 

A value parameter occupies the same number of words as a variable of the formal parameter type; a variable parameter 
occupies one word, which contains the address of the first word of the actual parameter. 

Components of the stack structure described above that are proven to be unnecessary in a particular subprogram are not set 
up. For example, a leaf procedure (one that calls no other declared procedure) does not need to save the return address in its 
stack frame; instead it can be left in, and on return be retrieved from, the SJNS. 

Unlike a declared procedure, the main program does not return to a caller; it jumps to P119, which ends the run tidily. 

The compiler keeps note of the library routines that have actually been called by a program and appends the Usercode 
source of only those routines to the object program. They are called using the simplest JSPp;... EXIT1; protocol, with 
any parameter(s) passed in the NEST. Calling only library routines is not considered to make a scope non-leaf. 
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2 Runtime diagnostics and symbolic dumps 


When a program terminates, P119 stores Q1 into Y1, Q2 into Y2 and the termination status code into Y3—0 indicates 
normal termination. On detected failure a specific error code number is stored in Y3, before the illegal order MRWDQO 
(‘rewind Flexowriter!’) is obeyed to force an abnormal end of execution. When MRWDQO is obeyed, ee9 may save the final 
state to pascal _core [Findlay3]. 


Traces are provided by ee9, though admittedly in terms of machine language and not Pascal source code. However, the 
assembly listing for the object program contains the corresponding Pascal source code lines, in the form of commentary, 
and this makes it easy to correlate the Pascal statements with the machine addresses provided by ee9. 


I intend that a future release will offer postmortem symbolic diagnostics, in the shape of the program paskal_post, 
providing source-language dumps of an object program’s final state as recorded in pascal_core. paskal_post will 
provide a clear account of the final state of a program, including a Pascal-format listing of the variables and parameters of 
active stack frames at the time of termination. It will do this by matching pascal_core with descriptions of its data, the 
latter having been filed away by paskal if the dump = yes option was in force. 


3 Runtime support routines 


The standard functions of Pascal fall into two groups: very simple, and somewhat complex. The former are implemented by 
the generation of inline code; the latter are provided by calls on subroutines. In addition, several Usercode routines can be 
appended to provide anonymous services that are best (i.e, most concisely) implemented in subroutines. These support 
routines are realized as Usercode procedures (P-routines) to avoid polluting the main program’s label space and to make it 
possible for them to have their own V stores (Usercode local variables). Apart from P119 and P118, which are included 
unconditionally, only those routines actually used by the source program are included in the object program. 


The current roster of support routines is as follows. 


P100 stacks, copies and compares structured values 

P101 computes N2 div N1 

P102 computes N2 mod N1 

P103 computes trunc(N1: real) 

P104 computes round(N1: real) 

P105 computes sin(N1: real) 

P106 computes cos(N1: real) 

P107 computes arctan(N1: real) 

P108 computes sqrt(NI: real) 

P109 computes 1n(N1: real) 

P110 computes exp(N1: real) 

P111 computes the integer power (N2: integer) ** (NI: integer), N1 =0 

P112 computes the real power (N2: real) ** (NI: integer) 

P113 computes the real power (N2: real) ** (N1: real) 

P114 ~—RIP114 initializes the heap; R2P114 implements new; R3P114 implements dispose 
P115 provides operations on sets 

P116 enables access to non-locals by getting the Frame Pointer of the nth-enclosing scope 
P117 handles failures, including subrange violations and overflows 

P118 shuts down the I/O subsystem (but does nothing at present) 

P119 ends the run; contains V stores used by the interim output routines 


P117 has a number of ‘side entries’, which act as follows: 
RIP117 puts the exit code in Y3, Q2 in Y2, Q1 in Y1, and AZO in YO, for paskal_post; fetches Y3 to the NEST 


R2P117 reports an ordinal subrange error 
R20P117 fails unless 0 < N2 < N1 
R21P117 fails unless 1 < N2 < N1 
R22P117 fails unless N2 < N3 < N1 
R23P117 fails if N2 < N1 

R24P117 fails if N2 > N1 


R3P117 reports an integer overflow 
R4P117 reports a real overflow 
R5P117 checks for storage exhaustion on entry to a procedure or function 


R50P117 reports a heap overflow 

R51P117 reports a stack overflow 

R6P177 fails on an unset result on exit from a function 
R61P177 fails on integer overflow or an unset function result 
R61P177 fails on real overflow or an unset function result 


R7P117 unused 
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R8P117 checks the validity of a pointer value 
R81P117 reports a nil or invalid pointer use 


R9P117 flags up otherwise unhandled failures 
R10P117 checks a case index and dispatches to a handler if the case statement is missing a limb 


R12P117 is a default handler for a case statement missing a limb 


P100 has a number of ‘side entries’, which act as follows: 


R1P100 stacks a structured value actual parameter 
R2P100 assigns a structured value 
R3P100 compares two structured values (/, r) in a manner analogous to the KDF9 SIGN order, 


returning -1 if/<r,0if/=r, and +1 if l>r 
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